Some databases can be viewed as being one or more tables. Typically, the table has one or more indexes to assist the user in finding information stored in the database. For example, if the database is a phone book, the main table may include a name, address, telephone number, and other useful contact information. One possible index on that table may be to reference names such that looking up a name may lead to a telephone number. Other possible indexes such as an index on the address or on the phone number itself, or other information are easily generated. Updates, such as a new telephone subscriber, are often entered into the database. However, the addition may take a significant amount of time based on the processing required to make a row or tuple level entry and consequently update the multiple indexes. The database itself may be partitioned according to some method, such as alphabetically, to produce multiple linked tables. Each of these tables have indexes and pages associated with each partition. An update to the data content of the database, or any row or column level operation, may require the update of the table, the associated indexes, and the pages as well. The update may well have a collateral ripple effect such that a relatively small change on the large database may take a long time to execute. The intensive processing effort it takes for extensive changes or other updates to the databases is undesirable because the processing effort may limit the availability of the database to other users.
One common problem with some databases is the update problem of discarding old data and the introduction of new data. Consider the case of a utility company that has a need to keep a rolling 90 day record of billing for its customers. In this case at the end of every month, the new billing charges should appear as recent charges and the oldest month of billing charges should be dropped or archived. This need for a “sliding window” of billing data involves two time intensive updates where the database becomes unavailable for a length of time needed to add a new billing period and drop or archive an old period. Such changes are not insignificant as the database is changed for every customer the utility services. The time period to perform this change may increasing grow as the utility grows in subscription. Additionally, the table may be unavailable during this period of changes. As the time for execution of a rolling change increases, so does the unavailability of the data.
Thus, there is a need for a technique that can allow for an improvement in speed and a reduction in unavailability with respect to the administration of changes to a database. The present invention addresses the aforementioned needs and solves them with additional advantages as expressed herein.